cmd-fetch: include overrides when updating lockfile #1387
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I'm working on a lockfile updater[1], and I'd like it to just be able to do `cosa fetch --update-lockfile` the same way a human would. This normally would run `rpm-ostree compose tree` without passing any lockfiles and blocking out the pool so that all packages come from the base repo. Sadly, that doesn't currently work for FCOS right now because we have an override for crypto-policies from f32 so that we don't pull in Python. And because we also have an `exclude-packages` for Python, without the f32 crypto-policies, we can't get a depsolve from just the base f31 repos. (This is the same issue that killed bodhi-updates[2].) As a short-term hack, just include the overrides for now. This dillutes the meaning of a "base" lockfile of course, because it will now include the packages from the overrides. I don't think this really matters for now though (it does make the checking for whether overrides are still needed harder, but I'd like to automate dropping overrides eventually too). Anyway, we can drop this hack once we move to f32, though I have some ideas too on how to solve this more correctly. [1] coreos/fedora-coreos-tracker#293 [2] coreos/fedora-coreos-config#335 (comment)
|
I'm having trouble following all the lockfile stuff honestly, and am still feeling it should probably be done via an explicitly maintained set of repos, but |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, dustymabe, jlebon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
I'm still happy with lockfiles. |
|
/retest bump CI because github is being unreliable |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm working on a lockfile updater[1], and I'd like it to just be able to
do
cosa fetch --update-lockfilethe same way a human would. Thisnormally would run
rpm-ostree compose treewithout passing anylockfiles and blocking out the pool so that all packages come from the
base repo.
Sadly, that doesn't currently work for FCOS right now because we have an
override for crypto-policies from f32 so that we don't pull in Python.
And because we also have an
exclude-packagesfor Python, without thef32 crypto-policies, we can't get a depsolve from just the base f31
repos. (This is the same issue that killed bodhi-updates[2].)
As a short-term hack, just include the overrides for now. This dillutes
the meaning of a "base" lockfile of course, because it will now include
the packages from the overrides. I don't think this really matters for
now though (it does make the checking for whether overrides are still
needed harder, but I'd like to automate dropping overrides eventually
too).
Anyway, we can drop this hack once we move to f32, though I have some
ideas too on how to solve this more correctly.
[1] coreos/fedora-coreos-tracker#293
[2] coreos/fedora-coreos-config#335 (comment)